home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Tools & Utilities
/
Collection of Tools and Utilities.iso
/
pascal
/
jpdoor32.zip
/
MULTI.DOC
< prev
next >
Wrap
Text File
|
1992-02-26
|
16KB
|
393 lines
┌──────────────────────────────────────────────┐
│ MOTOR CITY SOFTWARE │
│ ┌──────────────────────────────────────┐ │
│ │ JPDoor - Version 3.1 SE │ │
│ │ Copyright 1990 - 1992 │ │
│ │ ┌──────────┐ │ │
│ │ │\ │ │ │
│ │ │ \ │ │ │
│ │ │ \ P │ │ │
│ │ │ \ A │ │ │
│ │ │ │ S │ │ │
│ │ │ │ C │ │ │
│ │ 5.5 │ │ A │ 6.0 │ │
│ │ │ o│ L │ │ │
│ │ │ │ │ │ │
│ │ \ │──────┘ │ │
│ │ \ │ │ │
│ └──────────────\ │─────────────────────┘ │
│ The Ultimate \│ Door Writing Unit. │
└────────────────────┴─────────────────────────┘
This file contains information on writing doors that work in a multi-node
environment. While your door may not be multi-player, we would recommend
that you read over the following information anyways.
With the number of Multi-Node BBS's steadily increasing, we felt it was
very important to make it easy on the programmer to make his doors multi-
node aware. This release of JPDoor has many new features that make it easy
to write programs which work in a multi-node environment, even if you are
not running multi-node yourself. We have taken this one step further, in
that you can easily write doors which allow players to compete head-to-head!
While some of this may sound complex, it really is quite simple.
JPDoor will only allow multi-player games on RemoteAccess V 1.xx and
QuickBBS V 2.75. Future versions will also include full support for PCBoard.
SHARE MUST BE LOADED!
Some of the multi-node capabilities included are:
- Listing Other Users Currently Online
- Sending Online Messages to other users
- Determining the node number that the current user is logged onto
- Determining who is logged onto other nodes
- File/Record locking routines so your door can run on more than one node
at a time
- A method to ensure that your door is only run on one node at a time if
need be
- The ability for two nodes to pass data back and forth
This document is going to try to explain how to write a door which allows
two players, and passes game data back and forth between them. These
routines have been tested extensively, and while they appear to be working
fine, there exists a possibility that there are systems which may have
problems. Because of this, we will be working closely with anyone having
problems. If problems are discovered, then beta versions will be made
available to any registered user who requests it.
To start with, some basic concepts...
Multi-player doors will only work with QBBS 2.75 or RA 1.xx
All data is passed in a file called JPDOOR.USE which will be
created in the system directory pointed to by either the RA
or QUICK environment variable.
JPDoor has defined the structure for this file as follows:
TYPE
JPUseData = Array[1..2048] of Byte;
JPUSErecord = record
Name : String[35];
Line : Byte;
DoorName : String[20];
Status : Byte;
MaxPlayers : Byte;
Filler : Array[1..13] of byte;
MultiNode : Boolean;
PID : Integer;
Data : JPUseData;
End;
{ Status Byte : 0 - New Record Added }
{ 1 - New Data Written }
{ 2 - Data Has Been Read }
Var
JPUse : JPUseRecord; { Variable to hold MY record}
JPUseOther : JPUseRecord; { Variable to hold OTHER users record }
Lets look at each field :
Name - This is the name of the user currently online
Line - This is the node number the user is on. This does
not default to 1 like the dorinfo1.def does, and you
can get the users node with the function GetNode.
GetNode will simply search USERON.BBS for the users
name as defined in dorinfo1.def, and return the actual
node he is loggend onto.
DoorName - This is the name of your door. Its best to keep this to
15 characters or less. When JPDoor's Whoson procedure is
called, it will display this so other users can see that
your door is in use.
Status - This is used internally, and you need not worry about it.
The following values are used :
0 - New Record Added
1 - New Data Written
2 - Data Has Been Read
MaxPlayers - This contains the maximum number of users who can play
at one time. Currently, JPDoor will only support 2
players, but this will be increased in future versions.
MultiNode - True if your door allows more than one user to run the
door at the same time.
PID - If your Door is a multi-player door, then you MUST apply
for a Product ID code. You must be registered in order
to receive one. In order to test your door, use a PID of
0. If you attempt to use any other value, it will abort!
Data - This is where all the data is passed back and forth between
two nodes. This is explained in detail below.
A note about PIDs.
The PID is used to ensure that you only try to read data
written by YOUR door on another node. You dont want a
battleship door reading a data file from an X's and O's
door etc... The PID is validated internally by JPDoor.
The Value of 0 is for test purposes only, as we do not
want to force you to register BEFORE you can test it.
If you release a multi-player door using a 0 for a PID,
then you run the risk of it conflicting with other doors!
You will need a PID for each and every different multi-
player game you write.
There is no fee for registering a PID, and there is no
limit to the number of PIDs you may register, but you
must be a registered user of JPDoor.
PID 0 is ONLY for testing purposes, and you are expected
to register JPDoor and request a PID BEFORE you release
your door.
How it all works.
First, you need to decide what data you wish to pass back and forth.
Define a structure that is exactly 2048 bytes in size. An example
from my BattleShips door follows:
TYPE
Grid = Array[1..9,0..9] of Char; { Letter,Number }
NodeData = Record
Status : Byte;
PlayerName : String[25];
SeaGrid : Grid;
ShotN,
ShotL : Byte;
ShipHits : Array[1..6] of byte;
ChatLine : String[78];
Local : Boolean;
Filler : Array[1..1843] of Byte; {this is added to ensure that}